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CROSS-REFERENCE TO RELATED APPLICATION 

This application claims the benefit of US Provisional Application Number 60/390,292 
15 filed on June 21, 2002, entitled “SYSTEM AND METHOD FOR AUTOMATING THE 
DELIVERY OF CUSTOMIZED PURCHASE RECOMMENDATIONS RELATED TO 
THE SALE OF PRODUCTS USING A WEB BASED VOICE RECOGNITION 
SYSTEM”, and commonly assigned to the assignee of the present application, the 
disclosure of which is incorporated by reference in its entirety herein. 

20 FIELD OF THE INVENTION 

(002) The invention relates in general, to Internet based information filtering and 
recommendation systems. In particular, the invention relates to an automated purchase 
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(003) delivery system of customized purchase recommendations related to the sale of 
products using a Web-based voice recognition system. 

BACKGROUND OF THE INVENTION 

(004) One technique commonly used in e-commerce purchase recommendation systems 
5 is content-based filtering. In a pure content-based filtering system, recommendations are 

based upon similarities between the product features and the feature preferences of the 
purchaser. Pure content-based filtering systems used for e-commerce purchase 
recommendations have several limitations. First, they require the product to have 
distinguishable features that can be easily separated from the product in order to assess its 
10 similarity to the user’s preferences. Second, because of the “feature extraction” 
requirement, pure content-based systems are not well suited for the recommendation of 
products with subjective features like music. 

(005) A second commonly used technique is collaborative filtering. In pure 
collaborative filtering purchase recommendation systems, suggestions are made to users 

15 based on what products other users with similar preferences found relevant. This system 
does not make accommodation for the specific features of the product as is the case in 
content based filtering systems. Collaborative filtering systems are commonly based on a 
set of user ratings. Each user rates a set of products themselves in order to establish these 
ratings. Through this process, each user develops a ratings profile. Comparing profiles 
20 and extracting products that have not been rated by one user or another generate the 
recommendations. These yet “unrated” products are recommended to user who have 
similar profiles. 
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(006) As with content based filtering systems, collaborative filtering systems have their 
own set of limitations. The first limitation relates to the building of the ratings database. 
Since each user actually provides their personal ratings for a given set of products, the 
process of building a personal ratings profile can be time consuming. This process 

5 becomes even more cumbersome if users are not very familiar with some of the products 
that they are asked to rate. In addition, since collaborative systems work by relating users 
with similar tastes, the system does not work very well for users that have unusual tastes. 

(007) Another major issue is that collaborative filtering systems cannot recommend a 
product until it has been rated. At the launch of a new collaborative filtering system, 

10 since no products have been rated yet, the system cannot function at an optimal level until 
sometime in the future when a minimum level of ratings data is accumulated. 

(008) The corollary of the previous challenge is that once a very large database of user 
rating profiles is established, collaborative filtering systems tend to trade off efficiency 
for effectiveness. This occurs because the recommendation engine is required to compare 

15 a large volume of ratings profiles. In order to provide timely recommendations, the 
system will have to limit the number of profiles that are compared. This limitation, while 
enabling the system to deliver recommendations in a timely manner, will allow provide 
recommendations based on a limited analysis of the available data. This will increase the 
possibility of poor recommendations. 

20 (009) Finally, because collaborative systems are based strictly on the comparison of 

ratings profiles, there is no accommodation made for a user’s request for a specific 
category of item. In addition, since all products are treated with the same “weight”, there 
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can be no preference given to items that have been selling very well - only items that 
have been rated very well. 

SUMMARY OF THE INVENTION 

(00 10) The present invention has the ability to communicate with the user, not through 
5 text and graphics, but through voice commands and audio prompts. This feature is 
enabled with voice recognition and web technologies. This feature does not limit 
communication to desktop computers but allows the user to access the service via any 
telephone. Voice commands and audio prompts may, if desired, be implemented via a 
system comprising a speech application platform, core speech software and servers, a 
10 telephony interface, application servers and databases. 

(00 11) One aspect of the present invention is a product database. This database is 
designed with content layers and rating layers to facilitate the recommendation process. 
In an exemplary embodiment related to music: every ticket package is sub-divided into 
individual events; every event is sub-divided into individual pieces of music; and, 
15 individual pieces of music are sub-divided into individual attributes (such as composer, 
conductor, featured instrument). Finally, the system manager rates each attribute. This 
data structure allows for both content-based filtering and collaborative filtering, directly 
compensating for many of the limitations of pure content based filtering systems and pure 
collaborative filtering systems. 

20 (0012) The present invention may, if desired, have a Parallel Database that has data 

structures for creating relationships between similar composers (or other key attributes). 
These data structures may, if desired, be used in the event that the user’s preferences do 
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not match with any of the existing product attributes or the user has declined all prior 
recommendations and no further matches exist. 

(00 13) One method that leverages this overall data structure uses content-based filtering 
to match user product preferences to the existing data structure that contains the parsed 
5 product features. When a user initiates a call with the recommendation system, the user 
will be required to input their product feature preferences. The user will input (using their 
voice) their preferences and the system will compare these preferences to the parsed 
product features that make up the data structure. This type of filter creates a very user- 
friendly interface for gathering product preferences. 

10 (0014) The second method that leverages the data structure uses collaborative filtering 

techniques to quantitatively address the more subjective issues that arise when 
considering product recommendations. Prior to the launch of the service, ratings are 
assigned to subjective aspects of each product attribute. For example - in an exemplary 
embodiment related to tickets for musical performances, how popular is a particular 
15 conductor? When matches are found in the content based filtering process, the rating for 
that matching attribute is used to compare and rank the various events and by extension, 
each ticket package. The highest ranked event or package is presented to the user. 

(00 15) The present invention returns recommendations that have considered exact feature 
matches as well as a predetermined set of quantitative ratings that can more specifically 
20 address subjective aspects such as popularity. Further, the present invention integrates the 
user’s feedback from the initial product recommendation into a second round of product 
recommendations. For example: If the patron does not like the selection of events that 
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feature a specific composer (in an exemplary embodiment related to music), the system 
can make additional recommendations that factor this dislike into the process. 

(00 16) The present invention addresses the above limitations of pure content based 
filtering systems and pure collaborative filtering systems. These combined limitations are 
5 addressed through the present invention that is based on a hybrid content-collaborative 
based filtering system to provide recommendations to users of an internet voice 
recognition based recommendation service. The present invention may, if desired, be 
used to generate performing arts event ticket purchase recommendations to users of a 
voice recognition based ticket service. Users of the present invention may, if desired, 
10 input their preferences with regards to their prospective ticket purchase by using their 
voice. The user’s preferences would be matched against the features of the available 
events and event packages and an appropriate list of recommendation(s) would be 
presented to the user over the phone by the automated system. After which the user can 
provide further feedback on the presented recommendations and refine the list of possible 
15 purchase items. This entire system is managed by a web based computer application that 
communicates with the user via voice recognition. 



BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 illustrates a top level block diagram of the present invention, 

Fig. 2 illustrates a top level flowchart diagram of the call flow of Fig. 1, 

Fig. 3 illustrates a flowchart diagram of a user who wants to purchase a ticket of 
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Fig. 1, 



Fig. 4 illustrates a flowchart diagram of a method of sorting and presenting the 

appropriate recommendations to the caller of Fig. 2, 

Fig. 5 illustrates a flowchart diagram combining the content based filtering 

techniques with the collaborative filtering techniques to return a list of 
customized purchase recommendations, 

Fig. 6 illustrates a schematic diagram of the data structure fields of Fig. 1, 

Fig. 7 illustrates a flowchart diagram of order confirmation of Fig. 1 , 

Fig. 8 illustrates a flowchart diagram of determining the most suitable upgrade 

offer. 

DETAILED DESCRIPTION OF THE INVENTION 

(0017) Figure 1 outlines the technical structure and components that will host and serve 
this Internet based system. 24 indicates the initiation of contact between the user and the 
system. 26, the voice application platform, will manage the contact with the user. It will 
5 receive the voice input from the user and will return pre-recorded audio responses/content 
back to the user. This server will communicate with two back end servers: 27 that will 
control administrative, organizational and patron activity & 28 that will control the static 
content such as the audio files. These servers will supply the voice application platform 
with the appropriate audio content. 27 will ran Iplanet Enterprise Web Server 6.0 (web 
10 server) and BEA Weblogic Server (application server). Because of the types of functions 
that will be required of 28, it will only be required to run Iplanet Enterprise Web Server 
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6.0. This software configuration is only one possible configuration. There are other 
widely available servers that would be acceptable. The database, 60, 55, 56, will host all 
the details on the programming such as event dates, features, attribute scores, the Parallel 
database as well as patron data such as name, address, phone number and past purchase 
5 history. 60, 55, 56 will run off an Oracle 8i database server. All servers will run off the 
Solaris 2.6 operating system. This software configuration is only one possible 
configuration. 21 represent the ticketing system that contains all of the seating 
arrangements and available seats for each of the events that are available for sale. These 
data structures will be accessed as needed depending upon the requirements of each 
10 incoming phone call. For example, not all phone calls will require access to information 
on the patron database or the ticket system. 22 & 23 represent the system’s ability to send 
outgoing text messages (22) and automated pre-recorded phone calls (23). 25 represents 
the server that will send out text messages to mobile phones. 

(00 18) In Figure 2, 1 illustrates the means by which a user can connect to the system. 
1 5 This system is designed to be accessed by phone. The user communicates with the system 

though the use of voice recognition. This means that the user is prompted for information 
with pre-recorded audio files. The user simply responds with his/her voice. The voice 
recognition software communicates with other parts of the system to facilitate the ticket 
purchase. The user can connect by either calling the central portal phone number or can 
20 call the box office phone number of the desired venue directly. Both phone calls will be 
directed to this system. The “portal phone number” refers to an 800-number that accesses 
the system from anywhere in the United States. The “box office phone number” refers to 
a local phone number that a ticketing organization utilizes for its in-city box office 
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operations. The use of two phone numbers is a convenience for the user. 2 depicts the 
greeting or greetings that the user will receive when first contacting the service. The type 
or types of greetings will be dependent upon which phone number the user contacts. The 
“greeting” refers to a pre-recorded audio file that is played for the user offering 
5 instruction on how to use the system and asking the user how they would like to proceed. 
In one exemplary embodiment, a unique user ID may, if desired, be established using 
either a patron number, phone number or a voice print during the Introduction phase. A 
voice print is “a unique audio pattern that is created by the sound of a person’s voice”. 
After completing the introduction and establishing a unique user ID for the caller, the 
10 system prompts the caller about their desired next step. 3 indicates the prompting of the 
user with a choice as to how to proceed with the remainder of the call. This prompt refers 
to a pre-recorded audio file that is played for the user asking them if they would like to 
purchase a ticket (4), or, in 59, receive answers to some frequently asked questions 
(FAQ’s) or make an inquiry into their account (such as changing their mailing address or 
15 verifying the delivery of recently purchased tickets). The steps involved in buying tickets 
at 4 are described in more detail in Figure 3 and in the detailed description below. 

(0019) The buying process 5, Fig. 3 determines if the user knows exactly which product 
they would like to purchase. Following the “Yes” branch leading from 5 implies that the 
user has initiated a call to this system for the purposes of purchasing a ticket to a specific 
20 pre-determined event (the user already knows what they want to purchase). This step 
begins at 6 with a pre-recorded audio file that asks the user which event he/she would like 
to attend. The voice input from the user is recognized by the voice recognition system in 
7 and is stored in the system’s memory. 11-13 involves prompting the user for their 



9 




preferences, if they don’t know exactly what they want to purchase. 11 involves 
explicitly asking the user for his/her preferences as they relate to a product. In one 
exemplary embodiment, preferences can relate to attributes of music concerts such as 
composers, conductors, guest artists, favorite instrument, pieces of music or time of the 
5 year. The system receives the user’s voice input in 12. Next, the system compares user’s 
preferences to the attributes of the available concerts and offers a customized set of 
purchase recommendations (13), which is discussed in more detail below with respect to 
Figure 4. Once the exact product is confirmed through interaction with the user, 8-10 
confirms the remaining details of the order. 8 represent a confirmation of the preferred 
10 day of the week for attendance. 9 represent confirmation of the seating choice for the 
user. 10 represent the steps required to complete the order. These steps are discussed 
more fully below with respect to Figure 7 - 42. The updated seating and pricing data is 
stored in a separate data structure, usually in the form of a web based ticketing system, as 
depicted in 21. 

15 (0020) Figure 4 illustrates a high-level overview of the method for determining possible 

product recommendations and presenting select product recommendations based on their 
score. After conducting the preference mapping process in 14 for which further details 
will be discussed below with respect to Figure 5, the next step, 29, is to determine the 
type of ticket product the user would like to purchase: a subscription or a single event 
20 ticket. A “subscription” refers to a pre-determined package of events that must be 
purchased as a group also referred to below as Event Group. All the possible options 
(both subscription and single event) were ranked from highest to lowest according to 
their Event Group Scores (defined below) and Event Scores (defined below) in 31 & 30 
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respectively. For either of these options, the system presents the highest ranked option, in 

32 & 34. The presentation of options continues until the user accepts one of the options in 

33 & 35. 36 represent the end of the recommendation presentation process. 

(0021) Other possible applications of this system beyond those related to symphony 
5 orchestra ticketing include: ticket sales of opera performances, live theater performances, 
ballet performances, museum exhibits, live popular music performances and other non- 
arts/non-performance related applications including but not limited to professional 
baseball, football, hockey and basketball. 

(0022) Figure 5 illustrates the method for mapping a user’s preferences over top of a 
10 predetermined set of product options. This method utilizes both content based filtering 
techniques (Figure 5-16) as well as collaborative filtering techniques (Figure 5-17, Figure 
5-18). In 15, the system retrieves each attribute preference that was inputted by the user. 
In 16, each event attribute is compared to each event attribute in the event data structure, 
60. 16 is therefore utilizing content-based filtering because it creates an initial group of 
15 possible product recommendations by comparing the similarities between the users’ 
preferences and the product features. 17 and 18 are, in turn, and as more fully described 
below, utilizing collaborative-based filtering techniques, because they work together to 
quantify the possible product recommendations by matching a current user’s product 
preferences of certain product attributes with a pre-existing set of product ratings created 
20 by those with expert knowledge in a particular field of the embodiment. Therefore, 16, 
17, and 18 work in tandem to provide the benefits of content-based filtering and 
collaborative-based filtering, while at the same time accommodating for the shortfalls 
inherent in each process. Throughout the entire process, content-based filtering and 
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collaborative-based filtering respond to user input, as discussed above, using a web based 
voice recognition system. 

(0023) To achieve the result of content-based filtering and collaborative-based filtering 
working in tandem, using a web based voice recognition system, certain “scores” are 
5 used to by the system to assign value to users’ preferences and ratings. 

(0024) Thus, in an exemplary embodiment related to music performances, RS refers to 
the Relevance Score, which denotes the relevance of a particular attribute to the 
evening’s performance. In an exemplary embodiment, attributes are given a score of 0-3. 
A score of “0” represents the lowest and “3” represents the highest. For example even 
10 though Mozart is a very prominent composer, some of his pieces are very short and may 
not be the featured piece being played that evening - it may lack “relevance” to the 
evening and would likely get a score of 1 . 

(0025)P5 refers to the Prominence Score. This particular score denotes the prominence 
of the attribute to the classical music world as a whole. In an exemplary embodiment, 
15 attributes are given a score of 0-3. A score of “0” represents the lowest and “3” represents 
the highest. For example, Mozart will always receive a very high prominence score but 
may not always receive a very high relevance score. There are some lesser-known 
composers who most likely always receive a low prominence score but may on occasion 
receive a high relevance score depending on the piece that is being performed. 

20 (0026)45 denotes the Attribute Score, which is defined as a quantitative representation 

of both the degree of prominence and the degree of relevance of a particular event 
attribute, and refers to the product of RS multiplied by PS. An “event attribute” is defined 
as a unique feature of a particular event that comprises one of the core elements of the 
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event, in one exemplary embodiment. Generally, the event attributes are the basis upon 
which ticket purchasers desire to purchase one particular event instead of another event. 
AS is calculated for each attribute, as more fully described below with respect to Figure 
6, and provides 

5 (0027 )ES denotes the Event Score, which is defined as the sum of all the Attribute 

Scores that correspond to the event attributes that match the user preferences. 

(0028) An Event Group is a pre-determined package of events that must be purchased as 
a group, also referred to above as a subscription. EGS denotes the Event Group Score, 
which is defined as the sum of all Event Scores within each Event Group. 

10 (0029) In operation: The content-based filtering and collaborative-based filtering work in 

tandem with a web-based voice recognition system, in an exemplary embodiment relating 
to music performances, if a user indicated that “Beethoven” was a preference, the system, 
through 16, would search for a match between the user preference and the event attribute 
within the event data structure that contains all the event attributes (See Fig 6). If a match 
15 is found, then the Attribute Score (AS) is added to the Event Score (ES), in 17, and to the 
Event Group Score (EGS), in 18. The Event Score, in Figure 5-17, and the Event Group 
Score, in Figure 5-18, form the basis of the collaborative filtering process because they 
work together to quantify (or score) the possible product recommendations by matching a 
current user’s product preferences of certain product attributes with a pre-existing set of 
20 product attribute ratings created by those with expert knowledge in a particular field of 
the embodiment. This filtering process ranks all events and event groups based on these 
scores. This scoring (or rating) process enables the system to quantitatively provide 
recommendations to users. The result is a recommendation offered to a user via content- 
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based filtering and collaborative-based filtering, using, as described more fully above 
with respect to Figure 1 . 

(0030) At the beginning of a user’s call into the system, ES and EGS are 0. As the 
system, through 16, 17, and 18, matches attributes, this number will increase. The 
5 matching process that compares a user’s preferences (Figure 3-12) to individual event 
attributes is referred to in Figure 5-16 and described in more detail above. This process 
forms the basis of the content-based filtering process, because it provides a 
recommendation to a user by comparing the similarities between the users’ product 
attribute preferences and the event attributes. The ES and EGS are quantitative measures 
10 of how closely a user’s preferences match the product attributes of the available event. If 
no match is found between the user’s preference and an event attribute, then the system 
will begin another mapping process with the next user preference in 19. 20 represents the 
end of preference mapping. 

(0031) In an exemplary embodiment of the invention, the following business rules 
1 5 (which are electronic instructions pre-programmed into the system in order to guide the 
various processes) will generate the optimal ranking of options: 

1. If the system finds a match between a user’s “composer” or “piece of music” 
preference and an event attribute, the system shall add the Attribute Scores for both 
the composer and piece of music to the Event Score and not just the score of the 

20 matching attribute. 

2, If the system finds a match between a user’s “Guest Artist” or “featured instrument” 
preference and an event attribute, the system shall add the Attribute Scores for both 
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the Guest Artist and featured instrument to the event Score and not just the score of 
the matching attribute. 

(0031) These rules are necessary since there is a natural connection between the Attribute 
Scores of “Composer” and “Piece of Music” and of “Guest Artist” and “ Featured 
5 Instrument”. For example: A user inputs a preference (in Figure 3-12) for “Beethoven”. 
By stating this preference, the user is implying that they would prefer to attend a 
performance featuring a prominent, well-known piece of music by Beethoven. Since the 
Attribute Score for “Beethoven” doesn’t account for the type of music that is being 
performed, a business rule needs to be established to account for the “Piece of Music” in 
10 the overall ranking of the recommendation options. This is accomplished by adding the 
Attribute Score for “Beethoven” to the Attribute Score of the “Piece of Music” in Figure 
5-17. A similar rational exists for adding the Attribute Scores for “Guest Artist” and 
“Featured Instrument”. 

(0032) Figure 6 is a representation of the event data structure in an exemplary 
15 embodiment related to music. This data structure forms part of the database, 21, noted in 
Figure 1 . This particular data structure is an example of an embodiment as it relates to 
symphony orchestra ticket sales. However similar data structures can be applied to other 
types of ticket sales, as noted above. In the cases of these additional embodiments, the 
equivalent event attributes would be as follows: 

Symphony Event Opera Event Ballet Event Live Theater 

Attributes Attributes Attributes Event Attributes 

Name of Piece Name of Opera Name of Ballet Name of play 



15 




Composer 


Composer 


Composer 


Playwright 


Featured 








Instrument 


n/a 


n/a 


n/a 


Conductor 


Director 


Choreographer 


Director 


Guest Artist 


Soloist(s) 


Lead Dancer(s) 


Lead Actor(s) 



(0033) General definitions of data structure elements: 

Columns A & B: Together these two columns refer to the Event Group. In certain 
embodiments, there may be only one column of information representing the Event 
5 Group. 

Columns C, D, E & F: These columns represent information pertaining to the date of 
each particular event. “C” represents the time of day. “D” represents the day of the week. 
“E” represents the month of the year. “F” represents day of the month. 

Columns G, K, O, S & W: These columns represent the related Event Attributes for each 
10 particular event in this exemplary embodiment. “G” represents the name of the piece of 
music. “K” represents the composer. “O” represents the featured instrument. “S” 
represents the conductor. “W” represents the guest artist. 

Columns H, I, J, L, M, N, P, Q, R, T, U, V, X, Y & Z: These columns represent the 
Relevance Scores, Prominence Score and Attribute Scores. More detailed descriptions of 
15 these scores are noted above and below. “H, L, P, T, X” represent the Relevance Scores 
for their respective Event Attributes. “I, M, Q, U, Y” represent the Prominence Scores for 
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their respective Event Attributes. “J, N, R, V, Z” represent the Attribute Scores for their 
respective Event Attributes. 

(0034) For example: An event from the “Classic Al” Concert Group is being performed 
on Thursday March 28. It features the piece “Sinfonia from Easter Oratario” by “Bach”. 
5 This composition is an “Orchestral” piece being conducted by “Nicholas McGegan”. 
There is no “Guest Artist”. This example shows how the Event Attributes in the data 
structure are related. 

(0035) In this exemplary embodiment of the data structure, each music piece is 
associated with its related event attributes such as conductor, composer, date, etc. The 
10 related event attributes are found by reading horizontally across the columns. The most 
common attributes are noted in this sample data structure but this should not be 
considered a complete list. Additional attributes can be easily added and integrated into 
the method when required. Attributes will be different for other types of performing arts 
organizations such as opera companies, ballet companies and theater companies (see 
1 5 above chart). 

(0036) As discussed above with respect to Figure 5, RS refers to the Relevance Score. 
This particular score denotes the relevance of this particular attribute to the evening’s 
performance. In an exemplary embodiment, attributes are given a score of 0-3. A score of 
“0” represents the lowest and “3” represents the highest. For example even though 
20 Mozart is a very prominent composer, some of his pieces are very short and may not be 
the featured piece being played that evening - it may lack “relevance” to the evening and 
would likely get a score of 1 . 
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(0037) PS refers to the Prominence Score. This particular score denotes the prominence 
of the attribute to the classical music world as a whole. In an exemplary embodiment, 
attributes are given a score of 0-3. A score of “0” represents the lowest and “3” represents 
the highest. For example, Mozart will always receive a very high prominence score but 
5 may not always receive a very high relevance score. There are some lesser-known 
composers who will likely always receive a low prominence score but may on occasion 
receive a high relevance score depending on the piece that is being performed. 

(0038) AS denotes the Attribute Score, defined more fully above with respect to Figure 5, 
and refers to the product of RS multiplied by PS. An Attribute Score (AS) is calculated 
10 for each attribute. For example the RS# in column H multiplied by the corresponding PS# 
in column I equals the resulting AS# in column J. This score is a quantitative 
representation of both the degree of prominence and the degree of relevance of a 
particular event attribute. 

(0039) Multiplying the RS and PS is important to maintaining the integrity of the scoring 
15 system. Since both RS and PS are critical “dimensions” to the overall scoring of each 
particular attribute, having one or both of these factors rated as “0” should negate the 
value of the entire attribute. This result can only be generated if RS and PS are multiplied 
(as opposed to added). If either of these scores have a value of “0”, the resulting score AS 
(RS x PS) will also be “0”. 

20 (0040) Multiplying (instead of performing some other mathematical operation) also 

enables the system to become a sales tool and not just an information delivery tool. In 
order for this system to perform a sales function, it must be able to “act” like a sales 
person would act. This means that it must understand what factors are important and what 
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factors are not important from the perspective of the ticketing organization. It must also 
be able to offer the user accurate recommendations based on the subjective knowledge of 
the ticketing organization. 

(0041) For example: In an exemplary embodiment related to music, a symphony might 
5 choose to assign a rating of “0” to the Prominence Score for a particular composer since 
this composer is unknown to most, if not all, potential patrons. Because the composer is 
unknown, the symphony may decide that they do not want this particular attribute to have 
any influence on the outcome of any potential recommendations. Because this composer 
does have some relevance to the evening’s performance, a rating of “2” is assigned as the 
10 Relevance Score. 

(0042) By multiplying these two scores we arrive at an Attribute Score of “0” (0 
multiplied by 2). This score of “0” will mathematically have no bearing on the Event 
Score, Event Group Score or any recommendation that may be generated by the system. 
However, if we were adding the RS and PS (instead of multiplying them), the AS would 
15 be “2” (0 plus 2). Since the AS would be a positive number, it could have an influence on 
the recommendations that are made to the user (in contradiction to the wishes of the 
symphony orchestra). 

(0043) Scores can be assigned using any kind of scale deemed necessary. The larger the 
rating scale, the greater the level of specificity can be established for differences between 
20 various Event Attributes. For example: a rating scale of 1 - 5 can be used instead of a 
scale of 1-3, as noted above. With a scoring range of 1-5, there are a greater number of 
possible Attribute Scores and therefore more opportunity to distinguish the differences 
between Event Attributes. 
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(0044) RS and PS are just two of the most common attribute measures. Additional 
scoring criteria can be added to further enhance the systems ability to filter subjective 
measures of a user’s preferences. 

(0045) Figure 7 illustrates the process for completing the order. This process includes 
5 confirmation of the order as well as the determination of the upgrade offer at the end of 
the phone call. 37 & 38 interact with the caller to confirm the details of the product that is 
already in the shopping cart, represented by 58. A shopping cart is an accepted metaphor 
for the electronic record of the “events” that are chosen for purchase by the user. The user 
can recall this electronic record at any time. If, during the course of the phone session, 
10 there are events in the shopping cart that the user no longer wishes to purchase, the user 
can instruct the shopping cart (using a predetermined voice command) to discard that 
particular event. At the end of the phone session, the user is presented with all remaining 
events that are contained within the shopping cart. At this point, the user can choose to 
purchase any of the items in the shopping cart. The user will be instructed at that time 
1.5 with a series of steps that are required to complete the purchase. Details such as 
package/event, date, seating and price will be confirmed to ensure accuracy. 

(0046) If the user in 38 declines to confirm the order that is presented, then a pre- 
recorded audio file will be played to prompt the user to provide feedback pertaining to 
the factors that contributed to their decision to decline the order. An example of an audio 
20 file in exemplary embodiment related to music is: “Can you please provide us with some 
feedback? Was it the composer, conductor, guest artist, music, featured instrument or 
date of the concert that prompted you to reject the order?” 
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(0047) In 61, the user is allowed to provide feedback to the system. In 62, the user is 
given the opportunity to start the buying process again or to end the call. 

(0048) The business rules are applied to the confirmed order in 39 to determine the 
appropriate upgrade offer for this particular user. Business Rules are electronic 
5 instructions that guide the computer system, These instructions help the computer system 
simulate intelligent decision-making and help the computer system to decide upon a 
course of action in a multiple option situation. Simple business rules are generally 
designed with an “if X then Y” framework - where X is a current state and Y is the 
executable process required if the current state of X is achieved. The business rules are 
10 developed in conjunction with each ticketing organization based on their individual 
needs. These business rules can be customized for each deployment of the system and 

it 

allow the system to react in a unique manner to each customer based on a personalized 
set of user information. For example, in an exemplary embodiment related to music, if a 
user has selected the concert “Beethoven’s 9 th Symphony” for purchase and there is a 
15 business rule indicating that all purchasers of “Beethoven’s 9 Symphony” should 
receive 10% discount to “Tchaikovsky’s 4 th Symphony”. Then the 10% discount offer 
would become one of the upgrade offers that would be considered. There is not limit on 
the number of mutually exclusive business rules that could be established. 

(0049) 40-41 continues the interaction with the user by proceeding with the explanation 
20 of the upgrade offer and the confirmation of acceptance by the user. Specific descriptions 
of all of the upgrade offers will be stored in pre-recorded audio files. After the exact 
upgrade offer is decided upon by using the business rules (as noted in the above 
example), the system will play the appropriate audio file that describes the chosen 
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upgrade offer. At this point, the user will be given the opportunity to accept the upgrade 
offer for purchase (at which point the upgrade product will be “placed” in the shopping 
cart) or reject the upgrade offer. After a decision is made on the upgrade offer, all items 
in the shopping cart will be described to the user using a series of pre-recorded audio 
5 files. The user will then be given the opportunity to accept or reject all the items in the 
shopping cart. In 42, the final cost for the items that are accepted for purchase will be 
confirmed with the user. The user will then be asked for a mailing address and a credit 
card number to complete the purchase. 

(0050) Figure 8 illustrates the method for processing user related information to generate 
10 the optimal upgrade offer. The “optimal upgrade offer” is defined as the upgrade option 
that optimizes the user’s current purchase information, past purchase history, navigation 
log and if needed a Parallel Database. This involves applying a series of business rules to 
the various pieces of user related information that are available - including the shopping 
cart, navigation log, purchase history and parallel database. 

15 (0051) 45 compares the product that is currently in the shopping cart, 58, to pre- 

established shopping cart business rules to determine an initial list of possible upgrade 
offers. Shopping cart business rules are instructions that assist the system in determining 
the one or more possible upgrade offers. The instructions are constructed in the “if X then 
Y” format. With X representing product(s) in the Shopping Cart and Y representing 
20 corresponding upgrade offer(s). 

(0052) At 46, the system needs to decide how many possible upgrade options exist. If 
only one upgrade option exists then the default upgrade offer will be presented. The 
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default offer is designated as such during system setup - it becomes part of the business 
rules. 

(0053) 47 will compare the user navigation log in 57 with the existing set of navigation 
business rules to help validate any products that the user had previously indicated were of 
5 interest. The “user navigation log” is an electronic record of all the voice inputs from the 
user. This includes every response that a user makes to any of the audio prompts that are 
generated by the system. “Navigation business rules” are instructions that guide the 
assessment of the available list of upgrade offers in relation to the user navigation log. A 
starting point is to execute a preference mapping process that would map the user’s 
10 preferences (as indicated in the navigation log) over top of the available upgrade options. 
This mapping process would result in a “scoring” of the available upgrade options based 
on the matches with user’s preferences. These scores are assigned to a calculation called 
Upgrade Option Score. The Upgrade Option Score is defined as the sum of all the 
Attribute Scores that correspond to the event attributes of the upgrade options that match 
15 the user preferences. The purpose of the Upgrade Option Score is defined in more detail 
below. 

(0054) In another embodiment, a process could be implemented to map the user’s 
dislikes over top of the available upgrade options in order to eliminate options that would 
likely not be desirable for the user. In order to implement this embodiment of the 
20 invention, the user would be required to offer feedback regarding each product option 
that was presented during the phone session. This is accomplished by pre-recording an 
audio file that asks the user to indicate a specific factor that contributed to their decision 
to not purchase a particular product option. 
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(0055) For example, the audio file could contain the following dialog: “Please tell us 
which of the following factors contributed to your decision to decline the purchase of this 
event(s). Was it the composer, conductor, music, guest artist, the featured instrument or 
the date of the event?” This audio prompt would be inserted along the “No” branch 
5 leading away from 33 & 35 in Figure 4. The feedback offered by the user would then be 
registered electronically in the User Navigation Log. This information could then be used 
to eliminate any potential upgrade offers in 47 that contain the same factor(s) that 
contributed to the user’s decision to decline one or more of the original product offerings. 

(0056) An example of a scenario featuring this embodiment could demonstrate itself as 
10 follows: The user declines to purchase a particular event in 35 because they do not want 
to attend a concert that features “Mozart” (called the “rejection factor”). A navigation 
business rule exists in 47 that instructs the system to eliminate any possible upgrade 
offers from 45 that contain event attributes that match with any of the “rejection factors”. 
If there is an existing possible upgrade offer that features a piece of music by Mozart, 
15 then it will be eliminated as a possible upgrade offer at 47 because it matches one of the 
rejection factors, in this case - it contains a piece by Mozart. 

(0057) The next factor used to quantify and validate each of the possible upgrade options 
is the user’s past purchase history, 48. The user’s past purchase history is an important 
factor since it is reasonable to assume that there is a relationship between a user’s past 
20 purchases and that particular user’s propensity to purchase similar items in the future. 
This relationship is established by comparing the user’s stated event attribute preferences 
in 12 to the event attributes of that particular user’s previous purchases (if any) that are 
stored in a database 56. 
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(0058) This data structure containing the past purchase information is similar to the 
structure of Figure 6 but contains all events over the past three years along with their 
corresponding event attributes, Relevance Scores, Prominence Scores and Attribute 
Scores. This data structure is organized by ticket buyer name and patron number. If a 
5 match occurs between one of the user’s preferences, as stated by the user in 12, and one 
of the event attributes from a previous purchase, then the Attribute Score of that 
particular event attribute is added to the Upgrade Option Score of each upgrade option 
that also contains that same event attribute, allowing that particular event attribute to be 
factored into an upgrade offer. 

10 (0059) The purpose of the Upgrade Option Score is to enable the system to quantify and 

rank the possible upgrade offers. This is another representation of how content based 
filtering processes and collaborative filtering process are combined to generate purchase 
recommendations. 

(0060) For example: In an exemplary embodiment related to music: if “Beethoven” was 
15 one of the user’s preferences as stated in 12 and the user had previously purchased two 
Beethoven concerts with Attribute Scores of. ‘6’ and ‘9’ respectively, then a score of ‘ 15’ 
(6+9) would be added to the scores, as determined in 47, of each of the potential upgrade 
options that contained a Beethoven piece. 

(0061) If there is not a potential upgrade option that can be considered the “best” choice, 
20 in 49, (i.e. highest Upgrade Option Score with no ties), then the system will proceed to 
50. If there is an option that has a larger Upgrade Option Score than all of the other 
options, then the system will proceed to 53, where this particular option will be selected 
for presentation to the user. 
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(0062) In 50 the composers in the current shopping cart, in an exemplary embodiment 
related to music performances, will be compared to the Parallel Database, 55. A Parallel 
Database is defined as a data structure that contains the relationships between composers 
(or playwrights in the case of a live theater company) of similar style, genre or other 
5 significant artistic distinction. Experts, in their respective artistic fields, for each 
particular embodiment construct this data structure. It would be at this point that the 
criteria for comparison would be established. For example: a classical music expert will 
assist with the development of a data structure that is to be used in a symphony orchestra 
environment and it would be this expert who could advise upon the various comparison 
10 criteria (genre, style, etc.) that should be used for comparing composers. The data 
structure will cross-reference a particular composer (in the case of a symphony orchestra) 
with all other composers who compare favorably with respect to genre, style or some 
other acceptable artistic distinction. 

(0063) In an exemplary embodiment, the system would electronically access the Parallel 
1 5 Database for the list of cross-references between the first composer of the first piece of 
music from the first concert in the shopping cart and any other composers noted in the 
Parallel Database. The system would then electronically compare the list of cross- 
referenced composers with the all the composers that appear in the upgrade options. Each 
time an exact match occurs, that particular upgrade option receives a “point”. A “point” is 
20 used as a counter for the number of matches with the Parallel Database. These points do 
not have any relevance to the Attribute Scores, Event Scores or Upgrade Option Scores 
previously noted. Since, at this point of the process, we have at least two options that 
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have equivalent Upgrade Option Scores, the purpose of the Parallel Database is to 
determine one single upgrade option that is superior to all others. 

(0064) In an exemplary embodiment related to music: if the user has a concert that 
contains a piece by “Beethoven” in their shopping cart, the system would electronically 
5 access the Parallel Database for a list of cross-references between “Beethoven” and all 
other composers. Assuming that the Parallel Database considers Mozart and Beethoven 
similar in style, genre or some other accepted measure, the system would then search the 
available upgrade options for any Mozart pieces. The upgrade option with the most 
number of Mozart pieces would then be considered the preferred upgrade option. This 

10 process would continue until all composers noted in the shopping cart had been cross- 
referenced. 

(0065) In 51, if a there are two or more options that have equal ranking after this process, 
the upgrade option with the highest score after step 47 is considered to be the preferred 
upgrade option as depicted in 54. 

15 (0066) At 52, the system has already determined that there isn’t more than one upgrade 

option available to offer to the user. This can occur if a user’s shopping cart does not 
meet any of the upgrade requirements as set forth in the business rules. Since, the system 
will automatically have a default offer pre-programmed into its memory, this default 
offer will become the upgrade offer that is made to the user. 

20 (0067) Although only a few exemplary embodiments of this invention have been 

described in detail above, those skilled in the art will readily appreciate that many 
modifications are possible in the exemplary embodiments without materially departing 
from the novel teachings and advantages of this invention. Accordingly, all such 
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modifications are intended to be included within the scope of this invention as defined in 
the following claims, means-plus-function clause is intended to cover the structures 
described herein as performing the recited function and not only structural equivalents 
but also equivalent structures. Thus, although a nail and a screw may not be structural 
equivalents in that a nail employs a cylindrical surface to secure wooden parts together 
whereas a screw employs a helical surface, in the environment of fastening wooden parts, 
a nail and a screw may be equivalent structures. 




